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S-Language task Force 
From: R. delqard, D. Farber 

Subject: Proposed SPL 5-lanquage definition 

Date: 20/Uct//7 Memo No. 3 1 A 

Abstract: 

This document defines the data types* representations, anu operations 
for an 8 Pl s-lanquage for the FHP system. The language is greatly 
simplifiea over previous proposals oy the factoring out of all data 
addressing and type information into the namespace architecture. 
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1 Objectives of this Report 

Ihe intent of this document is to fully specify the formats, 
operations, and special conditions for an instruction set wnich can be 
used to efficiently implement normal SRL proarams. A number of 
forseen uses of SPL will require or be aided by extensions to the 
S-languade not specified here. These areas include 

Conversion, Editing, ana formatting 

Shared aata mediation 

Other kernel microcode operations 



All system calls are considered simply external calls into 
system-controlled domains. 

In addition, it should be possible to ado S-lan^uade operations 
in revisions of the S-language whenever it is found that such addi- 
tions would s i an i f i cant 1 v enhance the instruction set in some way. 
Such additions cannot reasonaoly oe forseen, out can only be deter- 
mined from dynamic statistics of real Programs. 



2 Data Types and Represent at i ons 

Ihe SPL s-language defines five types to represent all of SPl's 
data types and implicit structures. These data types are in general 
determined oy the opcode? the type field of the N TF is currently 
i gnored. 

ihe instruction set assumes a "hidden register" model. In this 
model, the type field determines how operands are placed into arbi- 
trarily large invisible registers - whether data is right or left 
adjusted, and if right adjusted, whether zero or sign filled. Opera- 
tions then manipulate such registers, and finally store bac< results. 
A number of exception conditions occur when the result memory con- 
tainer is too small for the data stored in it. 

The operation definitions listed determine how such data is 
interpreted (e.g. as integers, bits, etc.). in most cases this 
implies no type checking on the part of the interpreter, merely 
assumptions made. 



2.1 Integers 

Integers come in two forms, which are distinguished oy their 
types in the name table and never by information within an s-language 
operator. Internally, all integers are represented identically as lo 
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bit signed quantities; all transformations of length ana/or signedness 
occur in the fetch and store steps of an instruction. 



2.1.1 Unsigned Integer 

Unsigned integers represent UPl enumerations (including mSlII and 
BuOLErtN), and intervals, whenever the lower bound 1 s non-negative. 
Additionally, unsigned integers will no douDt be used to represent the 
current lenyths of strings. 

An unsigned integer n Dits in length may represent any value in 
the range 0 to 2**n-l. The maximum length of an unsigned integer is 
6i pits (because the high order bit is used internally to store an 
implicit zero sign); the minimum length is L bit. 

Unsigned integers are internally riant adjusted ano zero tilled. 
All integer arithmetic and comparison operations interpret all integer 
values as signed. iflihen stored, unsigned values are truncated on the 
left? if the truncated part is not all zeroes, an integer overflow 
trap is taken. 



2.1.2 Signed Integer 

Signed integers represent all oPL intervals where the lower bound 
is negative. 

An unsinned integer n cits in lenath may represent any value in 
the range -2**(n~l) to 2**(n-l)-l. The maximum length for an unsigned 
integer is 64 bits? the minimum length is 1 bit. 

Unsigned integers are internally riant aajusted ana sign-filled. 
When stored, unsigned values are truncated on the left? it tne trun- 
cated part is not an extension of the sign bit (high oroer bit of the 
result) an integer overflow trap is taken. 



2.2 Real 

Heal values are used to represent the oPs_ gate type RpAl. Real 
values are always 64 bits in length, ana are representeu in "IBH 
standara" form (8 ait radix 16 exponent and 4q bits of signed 
mant i ssa) . 

Heal values are ieft aajusted ana zero filled. Wnen storea, the 
low order (rightmost) bits are truncated as necessary? this is a 
significance truncation wnich causes no trap. 
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2.3 Bit String 

Bit strings are used to represent SPL sets. Additionally# oit 
string operations are sometimes used on boolean values ana may oe used 
on arrays and strings of boolean values. 

bit strings are internally left adjusted and zero tilled. oit 
strings may have a minimum length of 1 and a maximum length of c** 32-1 
bits. 



2.4 Pointers 

Pointers are used for indirect addressing in the namespace 
architecture. I hey are used by the external CALL instruction# oy the 
"STORE_ POINTER" instructions# and by the "RtScRvE" instruction which 
returns an aduress in tne current frame. 

Internally pointers are left adjusted ana zero filled. They may 
be self relative# in which case only tne upper 4o bits are 
significant, or aosolute in which case all 1 2 6 bits are relevant. The 
SPL data type "pointer" is always represented by 168 oit aosolute 
pointers? short forms may be used internally within the compiler. 

The external CmLl instruction always pusnes a l2o bit pointer 
which may be absolute or self-relative. The kEoEkVc. and 5TuRc_b0lN J'EK 
instructions store any type of pointer# a trap is taken if the length 
is 46 bits and the Pointer is not self relative. The 
STORE_FULL_POiNTEK instruction always stores a 12o bit absolute U1D, 
even if it could be self-relative. 



2.5 Typeless data 

A number of 5Pi_ operations deal with data merely as sequences of 
bits# these include many of the move ana compare operations. The 
structured SPL data types - record# array# ana string - may only be 
used in such "typeless" operations (and of course all field selection 
operations provided by the namespace architecture). |he type field of 
operands in such operations is ignored# data is treated merely as bit 
strings of the length specified in the NTt. in this report we always 
call such data bit strings. 
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3 Operation Formats 

The formats of operations tor the o-lanquaye can be broken into 
tnree general categories: all operands are names, one operand is a 
self relative offset, and the first operana determines the total 
number of operands. 



3.1 Operators whose operands are all names 

Instructions of this format include all of the following forms of 
operation (where h ana aF are the names assigned to S-lanyuage opera- 
tions herein): 

a := constant 
a : - F ( a ) 
a : = S>F tb) 
a : = F(b,a) 
a := b F ( b , c ) 

Note that all operations starting with 4 could easily be eliminated, 
by, for example, replacing the operation a : =$F ( b , c ) with the sequence 
a:=c? a:=F(b,a). However, using ooth format appears to be a natural 
optimization for these common cases. 

Additionally the foliowina special operations fall into this 
category. 



GilTU n where n names a Pd offset value 

CALl. p 
CALL p(a) 

RETURN 

p := KFSERVE(n) reserves frame space 

RELEAbFtn) releases frame space 

INTERiTAl_LALL 

I.mTERNAL_RFTUKN 

STOKE __PulN TER 

STORF_FuLl PO INTER 

SHIFT 



3.2 Operators wnich include a relative program offset 

Operations of this format comprise most control flow operations 
with the exception of those which specify a target address using a 
name instead of a self relative opcode. The operands ni ... n j , if 
any, specify parameters of the predicate which determines whether or 
not to execute the oranch instruction. the operand i specifies a 
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signed* mbole offset relative to the beginning of the instruction, 
which is adued to the Pt if the branch is taken. 

I F_F ( a ) oot o i 
IFNliT_F(a) goto i 
I F_F ( a , o ) got o i 
IFNUT_F (,a,b) goto i 
I F_F ( a , b , c ) goto i 
I Fh'uT_F t a, b, c ) goto i 



uther operations involving PC offsets include: 



LuOP 

Comparisons with zero 
FlNU_FIhST_UNt 
F j. N U)_P R L V _0 N F 
GUTU 

LuNb_GO | 0 

cause the iterant) to be incremented by the increment value, ana then 
branches if the iterand has passed the comparand. This instruction is 
used to implement most for-loops, as well as internally compiled 
1 oops . 



3.3 Operators with a variable number of operands 

The S-language contains two operations with a variable numoer of 
operands, the architecturally defined external call instruction ana 
ret u rn„access instruction. 
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4 Special Conditions in the SPL S-lanyuage 

This section aeal s witn special conditions, especially trap 
conditions, which can oe encountered during s-languade execution. 
These conditions are as follows; 

Name resolution errors 

Instruction input and output errors 

Protection violations 

Control flow violations 

Long instructions 

Overlappinq instructions 



/«hen an error is encountered during execution, a trap is taken. 
The exact way this is done will not be defined here. Traps may occur 
within instructions only tor "long" instructions, which are so marked 
in this report . 



4.1 Name Kesolution Errors 

Any instruction with at least one operand which is a name may 
generate a name resolution error. This includes all instructions 
except the uOTO instructions. Errors occur when the nametaole or 
associated information is invalid or unreadable; tnese errors are 
described further in the namespace documents. 



4.2 Instruction Input and Output Errors 

Instruction input errors can occur when the type of an operand is 
not the type expected, or wnen the value of an operand is not within 
the legal range of values, or when the operand is iarger than the 
maximum acceptable size. This category includes overflow, underflow, 
and divide oy zero errors. In general, typechecking is not expected 
to be dynamically perforemd oy the interpreter, however there is 
nothing to prevent it in the future. Length checking however will 
probably done, and range checking where necessary (as in string 
assignment) must be done to insure validity of the operation oeing 
performed. Output errors can be considered to mean "output container 
invalid for result". This condition may arise in at least three ways; 
wnen an integer value would be truncated on a store (.this is an 
overflow or underflow), when in a memory to memory operation the 
destination field is not the same size as the source fiejcHs), and 
when the type of the container is not valid for the result, in 
particular, when results are pointers. 
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4.3 Protection Violations 

whenever an instruction causes a fetch or store to main memory, a 
Protection violation can arise. The details of this are specified 
elsewhere. 



4.4 Control Flow Violations 

ihree sorts of control flow violation may arise. hirst, the 
offset of a local branch instruction can be out of DOunas of the 
particular procedure/procedure object. Clhis sort of error may be 
subsumed oy protection checks on instruction stream; out sucn checks 
do not guaru aaainst invalid jumps out of tne current proceoure out 
within the procedure object.) 

The second sort of error occurs analogously when the offset tor 
modification of tne stack causes a stack to overflow or underflow, or 
wiien the si 2 P of a frame in reserve/release instructions is negative. 

Finally, errors m a , be oenerated in the execution of call ana 
return code. Sucn errors may arise via the kernel, or other 
s-language microcode, and hence are outside the scope of this paper. 
In general such errors may oe described simply as "entry point speci- 
fied is invalid", or "return packet on stack is invalid". 

4.5 Long Instructions 

A number of instructions in the bPl_ S-lanyuage may involve 
arbitrarily large amounts of data, and thus have some exceptional 
conditions. Primarily, sucn instructions must be i nter ruptaol e botn 
due to handling page faults and for handling external interrupts 
(which may of course involve process swappina.), and must be continua- 
ble after interrupt completion. 



4.6 Overlapping Operands 

it is important to note the effect of memory to memory instruc- 
tions whose source and destination fields overlap. For simplicity and 
generality, we specify that the operation of any instruction, long or 
short, in which the destination field overlaps any source fields, is 
undefined, and may vary from model to model. Tne single exception to 
this is the string assignment instruction, which implements a bit 
shift and is guaranteed to work in any direction and for any length. 
Of course, those instructions in which a source field serves as a 
destination field, for example, add a to t>, are not consioereu to be 



overl appi no. 
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5 SPL Operation Definitions 



Jhe t> P L operations are defined in detail below. i he Operations 
are classified (arbitrarily) as control operations* and 1* 2, and 
3-operand operators. 



5.1 Definition Format 

t ac h definition includes three sections. 

(He operands section defines tne types expected for each operand. 
In the case where integers* reals, and pits are distinguished, type 
checking may be required oy the interpreter to determine the required 
result type? in most cases the type of the operand can be assumed to 
be the type required. when the operand name given is "i", the operand 
is interpreted as a "k" bit signed value found in the i-stream, 
representing the number of nioMes from the start ot tne current 
instruction to the start of the destination instruction, if a branch 
i s t a ken . 

The semantics section aefines the operational semantics of the 
opcode. The functions "resolve" ana "evaluate" define the transforma- 
tion of a name to the address it specifies, and a name to tne value 
located at the address it specifies, respectively. Arithmetic opera- 
tions such as + and *, ana boolean operations such as loaical-and and 



1 ogi cal -compl ement , are assumed understood 
val ues. 


ooth for 


i nt eqe r 


ana 


real 


trrors are specified by error code 
defined in section b. 


letters. 


whicn 


are 


fully 



5.2 Control Operations 



5.2.1 GOTO i 



SfcMANl ICS 

crkoks 



Pu <- D C + <4*i ? 
b 
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5.2.2 L0NG_G0|0 nl 



n 1 : 

StMAN PICS: 
ERROkS: 
NO IE: 



i nt eaer 

PC <- PuPTR + evaluate! nl)? 
b 

allows "execution" of code by an interpreter 



5.2.3 IF_aEkO nl, i 



n 1 : 

SEMANTICS: 

ERROkS: 



5.2.4 IFNUT_ZERu nl. 



n 1 : 

SEMANTILS: 
ERROkS . 



bit st r i ng, i ntefler 
IF eva 1 ua t e ( n 1 ) = 0 

a , b , - 



bit string, integer, 
IF evaluate(nl) <> u 

a , b , - 



or real. 

ThFi'i PC <- PC + 4*i, 



real 

THEN PC <- Pl t 4*1? 



5.2.5 IF_GT_ZEPO nl, i 



n l : 

SEMANTICS: 

ERRORS: 



i nt eger 

IF evaluate(nl) > u THEM PC < - P u + 4 * l ? 
a , b 



5.2.6 I F_GE_7ERu nl, i 



n 1 : 

SEMANTICS: 

ERRORS: 



i nteger 

IF evaluate(nl) > = 0 I HeN PC <~ PC + a* i ? 
a, b 
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5.2.7 I F_LT_ZERU nl, i 



n 1 : 

SEMANTICS; 

EPkORS: 



i nt eger 

IF evaluate(nl) < 0 THEN Pc <- Pu + 4*1 

a , b 



5.2.8 I F_ LE_7EPu nl, i 



n 1 : 

SEMANTICS: 

ERRORS: 



i nt eger 

IF evaluatetni) < - u IHtM PC <- Pt + 4* i 
a , b 



5.2.9 Rt AL_I F_GT_ZEhO nl, i 



n 1 ; 

SEMANTICS: 

ERRORS: 



rea 1 

IF evaluate(ni) > 0 THtN PC <- Po + 4*1 

a / b 



5.2.10 RE AL_I F_bE_ZERu nl, i 



nl ; 

SEMANTICS: 

ERRokS: 



real 

IF evaluatetnl) >= u T HEM PC <- PC + 4*i 
a,b 



5.2.11 kEmL_I F_CT_ 7tRU nl f i 



n 1 • 

SEMANTICS: 
ERROkS ; 



real 

IF evaluate(nl) < u T FIEN PC <- PC + 4* l 
a , b 



5.2.12 RE AL_ I F_ lE_ZERU nl f i 
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StMANflLS: II" eval uate (.n 1 ) <= u |HtN PC <- PC + 4*i! 

ERkOkS: a,b 



5.?. 13 iF_SUBSET n 1 , n2, i 



n 1 / n2 : 
StMAN TICS: 



ERROkS: 



hit string C expected to be equal in length) 
It* logical-ANu t e v a i uat e C n 1 ) , 

1 op l c a 1 -CuMpLtMtN | (. eva 1 ua t e C n? ) ) J = U 

Then PC <- PC + «*i; 

a / b t — 



5.2.1A I F nO T St 'ti St.T nl f np, i 



ni f n2: bit string texpected to be e«ual in length) 

SEMANTICS: IP logicei-ANp ievaluate(nl)» 

i ogi ca I -COMPLEMENT fevaluatelnE))) 

<> u I M E N PC <- PC + <4*i? 

lRHOkS. a ^ b / * 



5.2.1b i F _F d IJ A L n 1 , r>d, i 



n 1 , n 2 : 
SEMANTICS: 

ERRORS: 



bit strings of same lenyth 
IP evaluate(nl) = evaluate! n 2) |HcN 
PC <- PC + <4 * i ? 

a r b / — 



5.2.1b 1FN0T_EQUAL nl, n2 i 



n 1 / n2 : 
SEMANTICS: 



bit strings of same length 
IF evaluate(ni) <> evaluate(nE) ThEw 
PC <- PC + 4* i ; 

a / b f — 



cRRORS 
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I F_C tSS nl, n2 , 


i 


n i , n2 : 


bit s t r i ngs 


SEMANTICS: 


IF evaluateCni) < evaluatetnl) TrlEN 
PC <- PC + 4*1 ? 


ERRORS: 


a , b , - 


NO |E: 


a < b it a ana b are ePual up to the ena of 
a and b is lonaer than a. 


i F hO 1 _CESS nl, 


n2 , i 



n i , n2 : 
SEMANTICS: 

tRRORS : 



hit strings 

I F eva 1 uat e tn 1 ) >= ev a 1 u a t e ( nd ) THEN 
PC <- Pt + 4*i; 

a,b,- 



5.2.19 I N T_ J. F _E u U A L nl, nd, i 



n 1 , n2 : 

ScMani ics: 



lPkOkS: 



i ntener 

IF evaluatetnl) = evaluateCn?) 1 Hc.N 

Pc <- Pc + 4*i; 

a , b 



5.2.20 i.NT_iFNO |_EQUA|_ nl, n? , i 



n x » n 2 : 
SCMANI ICS: 

ERRORS: 



i n t e g e r 

IF evaluatetnl) <> evaluatetnd) TriEu 
PC <- PC + 4*i ; 

a , b 



5.2.21 iNT_iFJ.tSS nl, n2, l 



n 1 , n2 : 
SCMANI ICS: 

pPRORS: 



i n t ege r 

IF ev a 1 uat e (. n i ) < evaluate(nP) |Hc.N 
PC <- PC + 4* i ; 

a , b 
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5.2.22 iNT_IFNOT_LESS nl, n2, i 



n 1 , n2 : 
SEMANTICS: 

ERRORS: 



inteaer 

IE evaluateLnl) >= evaluateCnE) TnEn 
Pi <- PC + 4*i ? 

a , b 



5.2.23 kEaL._IE_L.ESS n 1 , n2, i 



n 1 , n2 : 

StMANflCS: 



real 

IF evaluate(nl) < eval uate Ln2) TnEiM 
PC <- PC * 4* i ? 



5.2.24 RE AL_I EN0T_L£SS nl, n2, i 



n 1 , n2 : 
SEMANTICS: 



real 

IE eval uate (.n l ) >= e v a 1 ua t e t nt; ) ThEn 

PC <- PC + 4* i ; 



5.2.2b i F_I nRuUhDS nl. 



n2, n3, i 



n 1 , n2 , n3 : 
SEMANTICS: 



EPKOKS: 



i nteaers 

IF levaluate(nl) <= evaluate in*:).) a N v 
Cevaluate(n2j <= evaluate(n3)) I H c_ N 
PC <- pC + 4*i 

a , b 



5.2.2fa iFN0 I_INB0UNUS nl, n2, ni, i 



nl,n2,n3: integers 

SEMANTICS: IE t, e v a 1 uat e C n 1 j > evaluate Cn2}) Oh 

tevaluate(n21 > evaluate (n3)) TnEn 
PC < - PC + 4*i 

a, b 



tRKOKS 
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5.2.27 FlND_FiRST_n(\iF m, nc, i 



nl : 
n2: 

SEMANTICS: 



tPROrtS: 



bits 
i nt ege r 

temp <- e va i ua t e C n 2 j ; 

WHILE temp < lengthtni) R c. P L A T 

IF eval (resol ve(ni)ttemp) = "on" 
resol ve(n 2 ) <- temo, 
RtTURN? 

End if; 

t emp <•* temp - 1 ; 

END WhIlE; 

pc <- pc + 4 * 1 ; 

a / b f o t ** 



5.2.20 F I ND_PRE v_ONE nl, n2, i 



n 1 : 
n2 : 

SEMANTICS: 



ERRuRS: 



bits 
i nteger 

temp <- e v a 1 uat e ( n2 ) ; 

WHIlE temp >- 0 Rc.Pt A I 

IF e va 1 t reso I ve ( n 1 ) +t emp) = "on" 
resolve(nci) <- terno, 

return ; 

End if; 

temp < - temp - 1 ; 

End rlpeat; 
pl <- Pc + 4* i ; 

a , b , o , - 



5.2.29 LOOP nl, i 



i n t e Q e r 

IF evaluate(nl) > 0 T H F N 

resolve(nl) <- evaluatetnl) - 1; 
PC <- PC + 4* i ; 

ERRORS: a , b 



n 1 : 

SEMANTICS: 



then 



|HtN 
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5 . 2 . 3U CALL j, nO, nl, ... nj 



Architecturally Defined External CALL Instruction 



5.2.31 C ALL U nO 



Architecturally defined External CALL Instruction 
Restricted to 0 Parameters 



5.2.32 CALL! nO, nl 



Architecturally Defined External CALL Instruction 
Restricted to 1 Parameter 



5.2.33 RETURN 



Architecturally Defined External RETURN Instruction 



5.2.34 R E T U K N _A c C t S S j r nl* ... nj 



Architecturally Defined External RETURN Instruction 
with Dynamic Access Control Windows (dACs) 



5.2.35 INTEKNAL_CALL nl 



nl: integer 

SEMANTICS: SPS) <- PC offset of NEXT instruction: 32 oit 

SP <- Sp + 32; 

Pc <- PuPfR + eval uatefnl ) ; 
a r b t s 



ERRORS 
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5.2.36 INTERNAl — RETURN 



SEMANTICS: 
ERRORS : 



sp <- sp - 32 ; 

PC <- PuPfR + fetch(SPfO? bit unsioneo int) 
a , b , s 



5.2.37 RESERVE nl» n? 



n 1 : 

n2: 

SEMANTICS: 



ERROkS: 



i nteoe r 
pointer 

IF e v a 1 uat e ( n 1 ) < 0 then t ran ( rancjp_e r ro r J ? 
resolvetnE) <- c rea t e_poi n t e r (.SP ) ; 

SP <- SP + evaluatetni); 
a f s / i 



5.2.36 RELEASE nl 



n 1 : 

SEMANTICS: 

ERRORS: 



integer 

IP eval uate (n l ) < 0 then t rap t rang®_er ro r j # 
SP <- SP - eval uatetni) ; 
a t s f i 
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5.3 Single Name Instructions 



5.3.1 CLEAR ni 



n 1 : 

SEMANTICS: 

ERROkS: 



hit String 

resolvei.nl) < - z e ro_a 1 1 _b 1 1 s ( 1 enqt b t n i ) j 

3 f " 



5.3.2 SET nl 



n 1 : 

StMAN I ILS: 
E R k n h S : 



bit string 

resolvetnl) <- set_a 1 1 __b i t s t 1 engt h ( n 1 ) ) , 

3 / " 



5.3.3 SET_Tu_ONt nl 



n 1 : 

SEMANTICS: 
ERROkS ; 



i n t e g e r 

resolvetnl) <- 1 ? 
3 



5. 3. a CuMPLEMtNI nl 



n 1 : 

SEMANTICS: 

ERRORS: 



bit string 

resolve(ni) <- logical -CO hPlF ME NT t n I ) > 

3 f " 



5.3.5 NEGATE nl 



P} 1 • 

SEMANTICS: 

ERRORS: 



i nt epe r 

resolve(ni) <- U - eva 1 ua t e ( n l ) ; 

3 f O 
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5.5.6 AbSULUTt^VALUt nl 



n 1 : 

SEMANTICS: 
t R K 0 K s : 



i nteper 

resolve(nl) <- j. F evaluateCnlj <■ u I H t N 

( 0 - e v a I ua t e ( n 1 ) ) ELSt evaluatetni) 
a 



5.3.7 INCREMENT nl 



n 1 : 

SEMANTICS: 
tRKOKS : 



i nteqer 

resol vein j, ) <- evaluatetni) + 1 , 

3 / O 



5.3.8 DECREMENT nl 



n j • 

semantics! 

ERRORS: 



i nteaer 

resolvetni) <- evaluate(nl) - 1/ 

6/0 
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5.4 Two Name Instructions 



in the following description of binary Operations* unless 
wise noted* tne types of the operands named by nl and nt is 
to oe the same. 



5.4.1 SCOMPLEMEimT ni* n? 



n 1 * n2 : bit strings 

SEMANTICS; resol vein?) <- logical -CO MP|_E ME NT t n i ) * 

ERROkS : a * o * - 



5.4.? SiMECATF nl, n? 



n 1 * n? : 
SEMANTICS: 
ERRORS : 



integers 

resol ve (nd) <- 0 - e va 1 uat e t n 1 ) ; 
a * o 



5.4.3 $ABS0eU1E_VALuE ni, n? 



n 1 * n2 : 
SEMANTIC? : 



ERRORS: 



i nt ege rs 

lh evaluate(ni) < 0 TriEi* 

resol vein?) <- 0 - e v a 1 uat e C n 1 j * 
ELSE resoiveCn?) <- eva 1 uate C n 1 j ) * 

3 t Q 



5.4.4 SINCREMEN1 nl* n2 



n 1 * n2 : 
SEMANTICS: 
ERrOrS; 



i nt ege r 

r eso 1 ve ( n^ ) <- evaluate(ni) + 1; 
a * o 



other- 

expected 
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5. a. 5 SDELRfcMtMT nl, nP 



n 1 , n2 : i nt ege r 

SEMANTICS; resalvelnE) < - evaluate(ni) - 1; 

ERRORS : a , o 



5.4.6 RtAL^iMFoATE nl, nP 



n i , n? : real 

StMANl ICS: resol veini) <- u - evaluat^lni); 

ERROkS: a 



5.4.7 RE Aj A8SVAL nl, nP 



n 1 , n2 : 
SEMAM1 ICS: 



tRKOKS : 



5.4.9 MUVE nl , n2 



nl, n2: any ot same length 

b F M A N T 1 C b ; resolvelnp) <- evaluatelni); 

t^RORS : a,o,“ 



5.4.9 I NT_MyVE nl, n? 



nl, n2: integer 

SEMANTICS;: resolvelnp) <- e v a 1 uat e l n i ) ; 

ERRORS: a , o 



real 

IP evaluatei.nl) < 0 ThFrt 

resolve(nP) <- 0 - evaluatei.nl); 
Ei_St resolvelnp) <- evaluatelni); 

a 
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5.4. lo STURE_ROiNTFH nl, n2 



n 1 : any 

n?: pointer 

SEMmN I' ICS: resol ve(nc) <- c rea t e_Po i nt e r (. reso 1 ve t n i ) ) ? 

ERRORS; a , o 



5.4.11 ST ORE_F IJlL _P TR nl, n2 



n 1 : any 

n? : pointer 

SEMANTICS: resolvein^) <- creat e_f u 1 1 _pt rfresolve(nl)); 

ERRORS : a,o 

NO|E: c reat e_f u 1 1 _Dt r differs from create_Ptr - 

it never stores object-relative pointers and 
must nave a 12* bit container for it. 



5.4.1* SHIFT nl, n? 



nl: integer 

n? : bit string 

SEMANTICS: resolveln*) + n i <- evaluate(n?J 

tRRORS : a , - 

NOTE : nl may be negative for a left shift. 

Full container is shifted, no fill is done? 
this could be considered a "relative" move. 



5.4. IS C0UNT_0MtS nl, n2 



nl: bit string 

nP: integer 

SEMANTICS; resolvetn*) <- l uount of bits in eva|uate(nl) 

which are "on"J 

ERRORS ; 3,o,- 
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5.4.14 HOUND n 1 , n? 



n 1 : real 

n2: integer 

StMANTlCS: temp <- e v a 1 ua t e C n 1 ) 7 

temp2 < - i n t ege r w pa r t C t emp) ; 
i F temp > o 

It- f rac t i on_pa r t ( t emp ) > U.o iHlN 

temp2 <- temp2 + 1? 

ELSE 

IF f rac t i on_pa rt C tempi > U.b |HcN 

temp2 <- temo2 - 1/ 

resolve(nH) <- temPE? 

ERROrS : a / o 



5.4.15 TRUNCATE nl, n2 



n 1 : real 

n2: integer 

SEMANTICS: resolvetnH) < - l n t ege r_pa r t t e v a I uat e ( n 1 j ) ; 

ERRORS : a f o 

NOIE: I i nteger.part (a) I = largest inteoer 

less than or eauai to tat. 



5.4.1b ELUAT nl, n2 



n 1 : 
n2 : 

SEMANTICS: 



ERRORS: 



5.4.17 AND n 1 , n2 



n 1 , n2 : bit string 

SEMANTICS: resolvetnE) <- evaluate(nl) 1 op l c a 1 _ AwD 

eval uat e Cn2 J 7 

ERRORS; 3(0,- 



i nteqe r 
rea I 

tempi <- ev a 1 uat e Cn 1 ) ; 
temp2 <- U7 

resolvetnE) <- c r ea t e_rea 1 ( t emp 1 , t emPE ) J 
a 
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5.4.1b uR n 1 , nd 



n 1 , n2 : 
StMANTILS: 

tRKOKSs 



bit string 
resol ve (nd) 



3 t O f " 



<- eva1uate(.ni) logical_OR 
evaluate! n 2) J 



5.4.19 AND.COMPLEMFnT nl, nd 



n 1 , n2 : 
StMANTILS; 



bit string 

resolve(nd) <- evaluate(nl) loaical_OR 

lopical-complementC evaluate(n?j); 



5.4.20 AOL) n 1 , n2 



n 1 , n2 : 
SEMaNI ILS s 
ERRORS: 



i n t e Q e r 

resolvetnd) <- evaluate(nl) + evaluate Cn2) 
a , o 



5.4.21 SUBTRACT nl, nd 



n 1 , ri 2 : 
SEMANTICS; 
lRROrs: 



i nteaer 

resol ve(nd) < - evaluatetni) + evaiuate(n2) 
a, o 



5.4.22 MULTIPLY nl, nd 



n 1 , n? ; 
SEMANTICS ; 
ERRORS: 



i nt epe r 

resol ve(nd) <- evaluate(ni) * evaluate(n2) 

3,0 
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5.4.23 ulUUTIENT n 1 , n2 



nbn?: 

SEMANTICS; 

ERRORS : 
hO I E : 



i nteper 

resolve(nE) <- evaluate(nl) [integer uividej 

e va 1 ua t e ( n2 ) ? 

a , o 

integer divide can be defined as 
t runcat e ( rea 1 divide). 



5.4.24 REMAIN uFk n 1 , n2 



n 1 t n2: 
SEMANTICS: 



ERRORS: 
no | F : 



i nteaer 

resolve(n2) <- e va 1 au t e t nc) - 

(tevaluatefn?) Linteaer divide) evaluate(nl)) 
* eval uate(ni) ) 

a , o 

sign of remainder is sign of uivioend (n2). 
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5.5 Three Name instructions 



in the followinq i ns t r uc t i ons , unless otherwise noteu, tne types 
of the names in an instruction are expected to be the same. No type 
conversion is Performed in the instruction execution. 



5.5.1 $ANU nl, n2, n3 



n 1 , n2, n3 : bit string 

SEMANTICS: resolvetni) < - evaluate(ni) loPical_AhD 

eva I uat e ( n2 j 

t R R 0 K S : a , o , - 



5.5.2 *UR nl, n2, ni 



nl ,n2,n3: bit string 

St MAN TICS: resolvetni) <- evaluatetni) 1 a o i c a 1 _n r\ 

ev a 1 uat e f n2) 

ERRORS: S;Of * 



5.5.3 $ANl>_COMPLEMENT nl, nt, n3 



nl,n2,n3; bit string 

SEMANTICS: resolvetni) <- evalute(nl) logical_ANU 

logical _complement(evaluatetn2)J 



5.5.4 $ADD nl, n2 , n 3 



n 1 , n2, n3 : integer 

SEMANTICS: resolvetni) <- evaluatetni) + evaiuate(n2j; 

ERRORS: a,o 
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5.5.5 SSUBTkACT nl 



n 1 , n2, n3 : 
SEMANTICS: 
ERRORS: 



5.5.6 SMUlTIPlY nl, 



n 1 , nd, n3: 
SEMANTICS: 
ERROkS: 



5.5.7 SyUUTiFNT nl. 



n 1 , nd, n3 : 
SEMAN7 IBS : 

tRNOKSi 



5.5.8 SKEMAiNuF.H nl 



n 1 , nd, n3 : 
SEMANTICS: 



ERKOHS : 



5.5.9 RE Ai ADt) nl. 



n 1 , nd , n3 : 
SEMANTICS: 
ERRORS: 



,nd, no 



i nteaer 

resolve(n3) <- evaluate(ni) - evaluate! n 2 J ? 
a , o 



nd , n 3 



i nteger 

resol ve(nj) < - evaluate(nl) * evaluate! n 2)? 
a , o 



nd , no 



i nteaer 
resol ve Cn3) 



a , o 



<- evaluate(nl) 
eval uate (nd) 



[ i nteger ui v i aej 



, n 2 , n 3 



i nt eaer 

resolvel.no) <- evaluatetnd) - 

!(evaluate(n?) linteger divide) evaluate! nl)) 
* evaluate!nl)); 

8 f O 



n2, n3 



real 

resol vetnj) <- evaluateini) + eva I uate !n2 ) ! 
a , o 
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5.5.10 KEAL_SUR1RAC r nl, n?, n3 



nlfnif n3: real 

SEMANTICS: resolve(ni) <- evaluate(nl) - evaluate(n2) 

ERkOkS: a,o 



5.5.11 HFAL_MuL TIPLY nl, n2, n3 



n 1 , nE, n3 : 
•SEMANTICS: 
cRKOkS : 



real 

resolve(ni) <- evaluateCnl) * evaluateCn2) 
a , o 



5.5. IE REAL_RjLViOE nl, n2, n3 



n 1 , n a , n 3 : 
SEMANTICS: 
ERRORS : 



real 

resol ve(ni) < - evaluate(nE) / evaluateCnl) 
a , o 
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6 Possiole f-uture S-language instructions 

The flexibility of a mi c roprogrammab 1 e machine is on i y effective 
when it can be used to delay decisions (binding, architecture, 
contracts) until sufficient information is avaiiaole to determine just 
what instructions would be cost effective. 

While we are convinced that the instruction set provided in the 
previous section will be adequate for generating code for arbitrary 
SPL programs, it may become clear that in certain cases the micropro- 
gramming of key routines, for instance, formatting routines or special 
table lookup routines, would provide definite performance improvements 
for a large class of programs. 

The precise semantics of such routines snould not be determined 
now. Rather, completed systems software should be measured carefully; 
those routines which turn out to oe commonly used ana which are 
bottlenecks can be microcoded. In oroer to help insure that program- 
mers use common software to implement common functionality, ana thus 
assure that we have a fair cnoice of commonly usea interfaces to 
microprogram, it is necessary at this point to define and publicize 
libraries of low-level abstractions for use by hHp systems 
programmers. The SPL abstraction mechanism is ideal tor this t as k . 

eventually, those abstractions which prove to be very commonly 
used ana which could be significantly imrrovea ov microprogramming <ey 
routines, shoulo oe considered for such optimization. it is therefore 
important to ensure that small routines which can be programmed in the 
S-language can in aeneral also be microprogrammed. 

oelow we present a number of example routines, written at 
SPL-s 1 anguage level, which suggest themselves as candidates tor 
microprogramming eventually. 



6.1 SC Ai\t_FOR_CHARMCTEK nl, n 2, n3, i 



n 1 : 
n? : 
n3 : 



SLMAN (ICS: 



array of character 

character (arbitrary size char) 

unsigned integer 

Pc offset 

nj> : = 0 

a: it nllnol = n£ then return 

increment ni 

if n3 > length(nl) then goto i 
goto a 
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6.2 SC Ah_F 0R_oTk I uG nl, n2, n i 



n 1 : 
n?: 
n 3 : 
i : 

slman rics: 



string 

string (shorter than n ) 
unsiqnea integer 
of f set 
ni : = 0 

a: it n 1 mi : 1 engt h (n2) J = n2 tnen return 

increment no 

if n3 > length(nl) then aoto l 
aot o a 



6.3 TKANSLATE nl, n2 



n 1 : 
n2 : 

S t M A N 1 IcS: 



array o f character 
array of character 
temp ; = length f n 1 ) - 1 
a: ni [tempi := [n 1 It emp] j 

if (temp := temp-1) >= u then aoto a 



6. A HASH nl/ n2 



n 1 : 
n2 : 

SEMANTICS: 



string 
i nteqer 

temp : = length(nl) 
at n2 := xor (nd; n 1 It emp) ) 

if (temp := temp-1) >= 0 then goto a 



6.5 SC Ahi_FOK_j.N_SET ni, n2, n3, i 



nl : 
n? : 
n3: 



SEMANTICS: 



string 

array of bits 
unsigned i nt ege r 
offset 
ni : = 0 

a: if n 2 l nl [ ni J j is "on" then return 

i nc rement ni 

if n3 > length(nl) then goto i 
goto a 
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6.6 CuNVErtT_lNT_TO_bTKlNG nl, n2 



n 1 : 
n? : 

SEMANTICS; 



i nt eqe r 
string 

converts nl to right adjusted blank padded 
character string n2. 



6.7 Ar^A|_YZE_ R lAl nl, n2, n3 



nl : 
n2 : 
n3 : 

SEMANTICS: 



r ea 1 
i nt eger 
string 

set n d to base 10 exponent of nl 

set nj to mantissa of nl, a left adjusted 

string with decimal implictly at left 



6.8 FlNITt_STATE_TPAN6LATt nl, n2, n3 



n 1 : 



n2 : 
n3 : 

semantics : 



a : 



finite state taoles in some represent at i on 

of tuples <state, char, next stater output> 

string i nput 

string output 

state : = l 

index := u 

temp := output (.state, n2Lindexj) 

state := next state (state, n^ tinuexl J 

n3 [ i ndex 1 : = t emp 

if ternp = 0 then return 

increment index 

goto a 



6.9 FINITE.. ST aTE_CHECK nl, n2, n3 



n 1 : 
n2 : 
ni: 

SEMANTICS*. 



a : 



finite state taoles as above 

string i nput 

integer output 

state := 1 

index := 0 

temp ;= output (state, n2[indexj) 
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state := next state (state? tinuexl J 
nj> : = state 

if temp = 0 tnen return 
increment index 
oot o a 
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7 Appendix: S-language Summary Charts 



7.1 Operation, Operand Ivpe, and trror Summary 



Symbols in operands and errors columns have the following meanings; 



operands 



errors 



i - signed or unsigned int a - 
r - real o - 
d - oits (any type as such) s - 
p - poi nter b - 
o - immediate offset i - 



x - p of external entry point + - 
k - immediate operand count - - 
a - any type, not interoreted all 

* - operanu is stored into ail 



name resolution error 
result container size overflow 
stack violation (overflow etc.) 
pc violation (out of pounds, etc. 
input value incorrect 
kernel generated error condition 
long instruction, interruptable 
statements with "a" error may 
aenerate fetch protection errors 
statements with operands may 

generate store protection errors 



operation operands errors 



GOTO o b 

L0dG_GUTU i D 

1 F_ZERO D o ab- 

i FnO 1 _ZEkO d o ab- 

1F-GI-2EKP i o ah 

I F_Gt_zFR0 i o ab 

i F_LT_ZEdO i o ab 

IF__Lt_ZEK0 i o ab 

KF At I F_GT_ZERU r o ab 

HE AL_I f _GE_ZtRO r o ab 

KEAL_IF_LT_ZtRu r o ab 

REAL_IF_LE_ZEPu r o ab 

I F_SUB3ET b b o ab- 

IFfMOr_SUbStT b b o ab- 

1F_£GUaL o b o ab- 

I F imO I_EQUAl b d o ab- 

IF_LcSS D o o ab- 

1FN0T_LE3S b b o ab- 

INl_iF_EQUAL l i o ab 

iNT.lFNOT.tOUAL i i o ab 

INT_iF_J_LSS i i o ab 

lNI_IFf*OT„LESS i i o ab 
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REAL_IF_LE5S r 
R E A L_ I F N U T _L E S S p 
i F_I nBUUivDS i 

IFwOT_iNbOUNDS i 
FIND_FIRST_OnE b 

F I isi D P KE V_UNE o 

LOUP *i 

CALL k 

LALLO x 

CALLl x 

RETURN 

RETURN_ACCeSS k 
INI ERNAL_CAl.L i 
INI ERNAL.RlTuRN 
REbERVL i 

RELEASt l 

CLEAR *h 

bET *b 

5ET_T0_0nE * i 

COMPLEMENT *b 

N E G A I E * i 

ABSOLUT E_V ALUE *i 
INCREMENT *i 

DECREMENT *i 

^COMPLEMENT b 

4NEGATE i 

4AtiSuLUTE_ VAlUe i 
^INCREMENT i 

bDECREMFNT i 

REAL.NEGaTE p 

REAL_AbSVAL p 

MOVE D 

INT_MOVE i 

STORt„POIMTER a 
STURE_FULL„PTR a 
SHIFT i 

cOuNT_ONES b 

ROUND r 

TRUNCATE p 

FLOAT i 

AND b 

UR b 

AND.COMPLEMENT b 
ADD i 

SUBTRACT i 



r o 


ab 


r o 


ab 


1 1 o 


ab 


i i o 


ab 


* i o 


ab- 


* i o 


ab- 


o 


ab 


x a a ... 


abs + 
abs + 


a 


abs + 
ost 


a a • • • 


abs + 

abs 

DS 


*D 


as i 
as i 

a- 

a- 

a 

a- 

ao 

a 

ao 

ao 


*b 


ao- 


* i 


ao 


* i 


ao 


* i 


ao 


* i 


ao 


*r 


ao 


★ r 


ao 


*b 


ao- 


★ i 


ao 


*P 


ao 


*D 


ao 


*b 


a- 


* i 


ao- 


* i 


ao 


* i 


ao 


* r 


ao 


*b 


ao- 


*h 


ao- 


*b 


ao- 


* i 


ao 


* i 


ao 
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MULTIPLY 


i 


* i 




ao 


uUUTIEnT 


i 


* i 




ao 


KEF! A 1 NuEK 


i 


* i 




a o 


SAND 


b 


b 


*b 


ao 


SON 


b 


D 


*b 


ao 


sAND_COMPL£MlNT 


0 


O 


* h 


ao 


j> ADD 


i 


1 


* i 


ao 


SSUBl PACT 


i 


i 


* i 


ao 


^MULTIPLY 


i 


i 


* i 


ao 


SQUO TIEN! 


i 


i 


* i 


ao 


^REMAINDER 




i 


* 1 


ao 


PEA! AUD 


r 


r 


* r 


ao 


KEAL_SURTPaCT 


r 


r 


* r 


ao 


kfal_multiply 


r 


r 


* r 


ao 


REaI — DIVIDE 


r 


r 


* r 


ao 



7.2 SPL S-1anguage Punction Table 



Type of uperanu a 



Format of Function 


1 integer 


kEaL_ 


dies 


lF_f(a) goto b 


1 ZEkO 
1 NOT.ZERO 
1 UT„ZERu 
1 LT_ZERU 
1 bE_Z£R 0 
1 LE.ZERU 


zero 

nOT.ZEkO 

neal.gt.zeko 

RFaL.L i .ZERO 
KEAL.GE.ZEKO 
KEAL.LE.ZEKO 


ZtRu 

NUT.ZtRu 


IF__f(a,b) goto c 
i FNOT.f ( a f 0 ) goto c 


1 i N f _t Q U A L 
1 iNT.LESS 
i 


lOUAL 

pEAL.LESS 


EuUAL 
LlSo 
S uBoE 1 


iF_f(a,b,cJ goto d 
I FNOT.f ( a r b * c ) goto ci 


1 INbOuNuS 

i 






a : = f ( ) 


1 CLEAK 
1 sEr.ro.ONE 


CLEAR 


clear 

StT 


a : = f ta) 
b : = $ f ( a ) 


i negate 

1 ABSOlUTE.VaLUE 
1 INCREMENT 




cumplcMln r 
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I uELPhMLNl 



f (a) 


1 float 


kOuND 


CuUuT_0nFo 


f (a,h) 


i 

1 

1 

1 ADD 


TRUNCATE 
REAL_AbSV AL 
kFaLJMEGmTE 


A dD 


$ f ( a i o ) 


i SUdTRACT 




Ob 


f l a f b ) 


1 multiply 

1 OUUTiENT 
! kFMAINuEk 

1 

1 

1 

1 


KE AL_AuD 
kEaL_SuB TRACT 
REAL_MuL1 tpl y 
hEAL_DiVIDc 


AdD_C uMpLEMENT 



Miscellaneous Operations 



GOTO CAlL RlTuR.M MOVE 

i_Oi\iG_GuTu CAlLU RtTURi‘<_ ACCESS i M i v F 

LOOP LALLl I i\STt.RN Al_kF TURN oTuRc.PCU N f ER 

PlNQ_FiRsT_ONE INTERNAL _C ALL Rt StR VE sTuRt__PULL_POl nTl 

FlND_PREV_ONE RcLcAoE SHIFl 

10 1 

1 Objectives of this Report d 

2 Data Types and Representations d 

2.1 Integers d 

2.1.1 Unsigned Integer 3 

2.1.2 Signed Integer 3 

2.2Rea1 3 

2.3 bitstring A 

?. 4 Pointers A 

2.5 Typeless Data ...A 

3 Operation Formats . b 



3.1 Operators whose operanas are all names b 

3.2 Operators which include a relative program offset . . b 

3.3 Operators with a variable number of operands . . . . o 

4 Special Conditions in the sPL 3-language ( 



4.1 Name Resolution Errors 7 

4.2 Instruction Input and Output Errors / 

4.3 Protection Violations b 

4.4 Control Flow Violations b 

4.5 Lona Instructions b 

4.6 Overlapping Operands 6 

5 SPL operation Definitions ..10 

5.1 Definition Format 1 0 

5.2 Control Operations 10. 

5.2.1 GOTO i 10 

5.2.2 LONG.G0TU nl il • 



5.2.3 X F_ZERU nl » i 

5. 2. A 1FW0T.ZEK0 nl, i 

5.2.5 I F_GT_ZFRO nl, i 
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